Patrick Ball's profile

UX Thought process

The UX Product Creation Journey
My UX journey typically starts off with rounds and rounds of interviews. I try to do 1-on-1 interviews, but never more than 3 people at a time. Most projects end up with 7 or 8 rounds. These interviewees could be stakeholders, tool users, customers, VPs, and product owners. I always do interviews first, even before requirements. This strategy eliminates a lot of excess requirements, reduces group-think, allows me to see my own blindspots (how dumb I am at the beginning of a project), and it's a great way to lead people in product building. Most of the time, it's a lot of listening and furious note taking. 
Color coding is a huge time saver. I recommend Crayola gel pens.
Sometimes I forget my notebook, but I always remember to color code the difference between my questions and interviewees.
You can see there's a few people with some varying ideas. This is something you won't see in requirements, and it's a must have.
At this point, interviews have concluded, sometimes we already have requirements available, sometimes not. It helps me personally, to block out a user flow while looking through requirements to stress test the requirements and see if they work.
If requirements are incomplete, or they aren't matching up to the interview process, I typically have to audit and do some serious excel documentation.
I've only had to write requirements from scratch a few times, thankfully with some great help from BA's.
Next up is my understanding how the tool will fit within our platforms and the available components + APIs I'll have on hand. So at this point there could be a lot of research and googling stuff I don't have a clue about, here you can see I have no idea what YEXT is. ha.
Requirements are done and signed off at this point. Next we have to get user flows done. Sometimes I'll sketch this but it's not going to get approved on a napkin. I built out a reusable Axure library of UX schemas that all UXers could reuse in their own projects.
This schema was for the Enterprise asset library with feature lists that matched up requirement numbers.
In discovery, it was found the company already had multiple sites housing different enterprise assets. We wanted it all in one responsive site.
At this point requirements, user flows, and overall architecture are signed off on, so thus begins the tasks. Oh Excel. oh man...
I've been asked if this takes the place of a Jira or Rally tool, and I typically do this for myself and it turns into tasks that end up inside of user stories for the team.
This project was metadata intensive, and my technical background really helped. Here's a few tasks where I needed to itemize metadata types to get into AEM JCR nodes. 
JCR is typically found in Apache open-source projects. This was an AEM project built on JAVA.
This spreadsheet comprised all of the tagging that had to happen just for the product families. From there it was assigned to go into the backend and create all the tagging structure that would allow items to be searched and queried.
This is some serious UX if you ask me. No fonts, no code, just straight organization!
Now we're getting organized! Here's a list of 300 reusable design components we had on our platform and specific information about each one. I built this in another project but use it often to see what I have on hand for designers to get items built faster.
And finally, here is the web-based documentation that holds all of the UX information so that anyone in the company can see how the tool was comprised. This is a reusable cloud-based template in Axure that all the UXers in the company have access to download, reuse, modify, and contribute to their own projects.
Thank you.
UX Thought process
Published:

UX Thought process

Published:

Creative Fields